Certain storage servers known in the art implement an inode based file system to manage stored data. In an inode-based file system, files are stored in two pieces: (1) a chunk of data somewhere in the file system; and (2) an inode, which is a data structure containing information about the location, size, creation/modification/access times, ownership, access attributes of, and links to the file. Data storage is typically implemented as one or more storage “volumes” of physical disks, defining an overall logical arrangement of storage space. The storage devices are typically organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. Storage of information on the disk array may be implemented as one or more storage “volumes” of physical disks, defining an overall logical arrangement of disk space. The disks within a volume are typically organized as one or more groups, wherein each group may be operated as a Redundant Array of Independent (or Inexpensive) Disks (RAID). Each volume may be associated with its own file system.
Known storage operating systems typically contain a program to check and repair an associated file system (e.g., a consistency checker or a file system verification program). A file system verification program may be implemented to operate in two phases: an inode phase and a directory phase. In the inode phase, the file system verification program looks at each buffer tree associated with an inode. A “buffer tree” is a linked list of indirect and direct file data blocks, which, in turn, point to file data blocks on the disks that comprise the file system. The file system verification program moves down each buffer tree and verifies that all pointers are valid and that no cross links occur.
In the directory phase, the file system verification program verifies the directory structure stored within the file system. For example, the checking process may first iterate through all of the file inodes of the file system and then through all of the directories of the file system.
A storage system may implement so called flexible volumes, where the file system layout flexibly allocates an underlying physical volume into one or more virtual volumes of a storage system. To that extent, the sizing of flexible volumes is flexible, which avoids the partitioning of storage space and any resulting problems. A flexible volume is a logical volume within an aggregate that may grow or decrease in size. It is only constrained by limits set when it is created and the hard (physical) limits of the aggregate. The underlying physical volume may be an aggregate comprising one or more groups of disks, such as RAID groups.
As flexible volumes are special files in the aggregate, they require a different structure than normal to distinguish them from the other files of the system. For example, each flexible volume may be represented by a file in the aggregate, called a container file, which is hidden and stores all of the blocks used by the associated flexible volume. The aggregate may also include a hidden metadata directory that contains a list of all flexible volumes in the aggregate in a form of subdirectories, e.g.:                WAFL/UUID/filesystem file                    /storage label file                        
Specifically, a “physical” file system (WAFL) directory includes a subdirectory for each flexible volume in the aggregate, with the name of the subdirectory being a universal unique identifier (UUID) of the flexible volume. Each UUID subdirectory contains at least two files, a container file and a storage label file. The storage label file is illustratively a 4 kB file that contains metadata similar to that stored in a RAID label. In other words, the storage label file is the analog of a RAID label and, as such, contains information about the state of the flexible volume such as, e.g., the name of the flexible volume, the UUID and file system identifier (fsid) of the flexible volume, whether it is online, being created or being destroyed, etc.
In order for a system to distinguish between non-container files and container files, each container file in the aggregate is associated with a special type of inode (flexible volume type), designating the file as a container file. As container files are represented differently from non-container files within a file system and also have associated storage label files, in order for a file system verification program to check and repair a system that supports flexible volumes, the program should be able to recognize and handle container files, as well as the associated storage label files, in an appropriate manner. Flexible volumes may become “lost” in the sense that they are no longer accessible to the file system and/or user. These files are usually seen by the file system as file blocks that are of no use to the file system and are deleted. However, these lost flexible volumes may contain desirable information that would be lost if the file was deleted.